It’s a common problem: You have a bright, shiny new SharePoint installation, and you suddenly realize that before you can put it on the Internet, you need to set up SSL and redirect HTTP for all your Web applications. HTTP works fine for an intranet sometimes, but HTTPS and SSL are essential for Internet deployments for security’s sake.
Once an SSL certificate is installed, you need to find a way to capture any HTTP requests for your SharePoint server and redirect it to the SSL-encrypted site. At first you may assume there is a standard way to redirect HTTP to HTTPS in SharePoint, but after a little time combing the search engines, you’ll find out there isn’t.
There are several ways of dealing with an HTTP-to-HTTPS redirect; ASP scripts and the built-in HTTP redirect in IIS are two popular examples. In the SharePoint world though, where there can be so many different URLs to deal with, it can get to be a little tiring to create a redirect for each one. So how can we create one rewrite that will cover our SharePoint Web applications?
So let me introduce the URL Rewrite extension for IIS. Install the URL Rewrite by using the Web platform installer option, or by downloading the x64 version and launching it on your SharePoint Web front end(s). URL Rewrite is a Swiss Army knife of IIS optimization, and I am not even going to begin covering all the uses it has.
Before I go any further, however, let me caution you: URL Rewrite is powerful, but dangerous. Whenever possible, thoroughly try any rewrite rules in a test system before putting them in your live environment. Rewriting and redirecting SharePoint URLs can cause unpredictable or even damaging results; use extreme caution.
With that warning in mind, let’s set the stage for our example. Our test farm has multiple Web applications on the Contoso domain (team.contoso.com, portal.contoso.com, etc.) Each Web application is set to use a wild card certificate for *.contoso.com over HTTPS, and none of them any longer have a binding on port 80. For example, team.contoso.com:
Now we need a Web application that will capture all those HTTP requests, no matter which specific URL is the final target, team, portal, MySite, etc. This Web application does not need to be a SharePoint Web application; in fact it is better if it isn’t. It just needs to be bound to any requests on port 80, like this:
Once all that is in place, we just need to make a simple rule using URL Rewrite.
In IIS, choose your site that is bound to port 80, and choose the freshly installed URL Rewrite extension in the Features View of IIS:
In the far right-hand corner of IIS manager, choose Add Rule(s).
Name the Rule anything you like. As you can see in the screenshot above, mine is called 80redirect.
Fill out the Match URL section with the information below. In this case, the “pattern” is basically any request that comes to port 80:
In the Conditions section, click the Add button and enter the following information, then click OK.
The Conditions Panel will end up looking like this:
Skip the Server Variable section and go to the Actions panel and fill it out like you see below:
Once the Action section is complete, click Apply and, believe it or not, you are done:
At first, people may ask why URL Rewrite is needed or even wanted here, and the answer is simplicity. If you set up this redirect on your Web Front End(s), any request to an HTTP site will automatically be redirected to the correct HTTPS site. http://team.contoso.com redirects to https://team.contoso.com, http://localhost redirects to https://localhost; the redirect doesn’t care what the final destination is, so any new Web applications you create is automatically covered by the process.
Because of that, you probably don’t want to set this up on your app servers or servers that are doing search crawls, unless the crawl is happening on a port other than 80. But since all the changes are happening on an IIS Web application, and not one created in SharePoint, it can exist on some servers in your farm and not others. Is this the only solution? No, but for a simple way to make sure all your Web applications are covered, it works well and doesn’t require adjustment each time you create another Web application. I hope you find it to be useful!
Stephen Wilson is a consultant with SharePoint911, a Rackspace company.
